-
Notifications
You must be signed in to change notification settings - Fork 2
Update supported Python and package versions. #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Update supported Python and package versions. #14
Conversation
License Check Results🚀 The license check job ran with the Bazel command: bazel run //:license-checkStatus: Click to expand output |
40e06c1 to
4d68282
Compare
* [Python] Add mechanism to support EOL (legacy) Python versions Versions that are end of life (currently 3.8 and 3.9) are marked as legacy versions and have a separated requirements file to split dependencies and support both, legacy and stable versions. * [Python] Add new stable versions Add new stable versions (3.13 and 3.14). * [pip] Update dependencies Updated dependencies for tools, partly to support new versions , to have new features available, fix pip-audit findings or to be in sync with other S-CORE repos.
4d68282 to
28973f6
Compare
| - bazel_skylib >= 1.7.1 | ||
| - rules_python >= 1.4.1 | ||
| - bazel_skylib >= 1.9.0 | ||
| - rules_python >= 1.7.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - rules_python >= 1.7.0 | |
| - rules_python >= 1.6.3 |
according to MODULES.bazel
| for version in PYTHON_VERSIONS | ||
| ] | ||
|
|
||
| [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to issue the warning only if the selected python version is a legacy one?
|
|
||
| This will try to read the requirements.in file as well as | ||
| requirements.in_stable and requirements.in_legacy. In case one of those files | ||
| do not exist it will be simply skipped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| do not exist it will be simply skipped. | |
| does not exist it will be simply skipped. |
| if not requirements: | ||
| fail("No direct dependencies found in any requirements file. The created pip hub will be empty.") | ||
|
|
||
| return list(requirements.keys()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we anyhow return a list, would be possible to skip the dictionary step and just add the lists returned by _read_and_parse_requirements?
| [ | ||
| python_tool_common.Finding( | ||
| path=pathlib.Path("file.py"), | ||
| path=pathlib.Path(" file.py"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wa sthis change made on purpose?
| run_command "test/run_all_tests.sh" "tests (in test workspace)" | ||
| fi | ||
|
|
||
| if [ "${workspace}" == "all" -o "${workspace}" == "test_single_version" ];then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I would not have another test workspace, since it doesn't cover anything in addition to the already existing one. I guess test_single_version would be a good template for someone that just wants to use bazel-tools-python, but for that use-case I would rather update the documentation, if it is not good enough.
Anyhow, that's just my opinion and I asked a colleague of mine, what we want to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My colleague agree, we should stick to one test workspace.
| build --config=python_3_8 | ||
| build:python_3_13 --python=3.13 | ||
| build:python_3_14 --python=3.14 | ||
| build --config=python_3_12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it required to switch to 3.12 or is that a leftover from when you removed 3.8 entirely? If possible I'd keep 3.8 until we can really remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here my colleague also agreed. We have to test against 3.8 by default, to ensure no-one introduces anything that doesn't work with it.
[Python] Remove EOL versions
Remove versions that are end of life (3.8 and 3.9).
[Python] Add new stable versions
Add new stable versions (3.13 and 3.14).
[pip] Update dependencies
Updated dependencies for tools, partly to support new versions , to have new features available, fix pip-audit findings or to be in sync with other S-CORE repos.